System and Method for Management of Surveillance Devices and Surveillance Footage

ABSTRACT

A system or method of transmitting and receiving surveillance video and/or alarm data and converting proprietary video formats into a single, standardized format for viewing on a multiplicity of devices at the surveillance location by authorized emergency responders.

CROSS-REFERENCE TO RELATED APPLICATIONS

This non-provisional utility patent application claims the benefit ofprior filed U.S. provisional application Ser. No. 61/351,608 filed Jun.4, 2010, which is incorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to surveillance systems and methods foroperating them.

2. Description of the Prior Art

Traditional Digital Video recorders use proprietary software for thepurposes of remote viewing. When a large number of different DVR systemsare to be managed/accessed, this creates a problem in that the end useris required to have the proprietary software installed for each of theDVR brands they wish to access. These video files can also be very largein size. The size of video can create a significant delay in theirtransmission over a network. To convert these video images into astandardized format can also require the use of a very powerfulcentralized server. If a user is charged with the task of maintaining alarge number of different DVRs, a challenge arises in having to maintainlists of IP addresses, usernames and passwords, and location details foreach of the installed DVR units.

In addition, there is currently a large disconnect between DVR ownersand Law Enforcement agencies. Typically when an event occurs such as arobbery, it can be hours or days until surveillance footage of the actis available to law enforcement. This creates a significant delay in theidentification and apprehension of suspects that are caught on camera.There can also be a significant delay between the time an alarm occursand the time police are actually notified of the alarm. Law enforcementagencies also have the dangerous job of responding to burglar and panicalarms without having video or images of what waits for them inside ofthe establishment they are responding to.

There also exists a significant problem in false alarm rates; that is,law enforcement responding to panic and burglary alarms inadvertentlytriggered resulting in a police call and response. This creates afinancial hardship for law enforcement agencies as these wastedresources are deployed in situations where they didn't have to be.

U.S. Pat. No. 6,778,085 & US Pub. No. 20040004543 with J. Faulkner asinventor for a security system and method with realtime imagery,describes a security/surveillance system that uses an image capturingdevice to reproduce realtime imagery and/or video along with a computersystem and server linked to a network for transmitting realtime imageryto emergency response agencies.

U.S. Pat. No. 7,323,980 & US Pub. No. 20050068175 also with J. Faulkneras inventor for a security system and method with realtime imagery,describes a security/surveillance system that uses an image capturingdevice to reproduce realtime imagery and/or video along with a computersystem and server linked to a network for performing processes asdescribed above in U.S. Pat. No. 6,778,086/US Pub. No. 20040004543 withadditional features such as generating and transmitting biometricanalysis along with the structural attributes of the location andphysical conditions of the location.

U.S. Pat. No. 6,798,344 & US Pub. No. 20040004542 also with J. Faulkneras inventor for a Security Alarm System and method with realtimestreaming video, describes a security system that uses a video cameraand an alarm sensor to reproduce, process and display realtime streamingvideo linked to a network for activation of emergency response agenciesbased on a user's password and displaying realtime video at theemergency response agency depending upon valid password entry.

U.S. Pat. No. 7,719,567 & US Pub. No. 20060072757 assigned to SmartvueCorporation for a wireless video surveillance system and method withemergency video access, describes a surveillance system that uses animage capturing device and a digital recorder to transmit/receive datato a third party, which are described as any form of emergency responseunits, an alarm sensor to reproduce, process and display realtime videolinked to a network for transmitting/receiving/displaying live videostream or recorded video and generating video stream on command.

U.S. Pat. No. 7,719,571 & US Pub. No. 20090237504 also assigned toSmartvue Corporation for wireless video surveillance system and methodwith DVR-based querying describes a surveillance system that uses awireless image capturing device (ICD) and a digital input recorder (DIR)to generate/transmit/receive data to a third party, which are describedas any form of emergency response units.

US Pub. No. 20070182540 assigned to GE Security Incorporated for localverification systems and methods for security monitoring, describes asecurity monitoring system capable of image verification and/ordetection with the use of an image capturing device such as a camera togenerate/transmit data to a remote device and/or system; furtherdescribing the reproduction and transmission of visual image data alongwith audio/sound data, performing object recognition andbackground/foreground analysis, and generating an alarm based onverification and recognition data.

US Pub. No. 20060279423 with Soheil Nazari as inventor for a stand alonesurveillance system, describes a surveillance system comprising DVRs,video cameras and self-generating power source capable ofreceiving/generating and transmitting video images via network.

US Pub. No. 20040205823 assigned to Chic Technology for a residentialsecurity system, describes a security system with WEB cameras, WEBServers and DVRs for live surveillance via an established networktransmitted through a PSTN and a computer system.

US Pub. No. 20030128113 assigned to Accton Technology Corporation for anetwork communication device security system and method using of thesame, describes a security system that contains an image capturingdevice, digital video recorder, cameras and a network communication linkdevice capable of process, receiving and transmitting video image data.

U.S. Pat. No. 7,158,026 & US Pub. No. 20050174229 assigned to SecurityBroadband Corp for a security system configured to provide video and/oraudio information to public or private safety personnel at a call centeror other fixed or mobile emergency assistance unit, describes asecurity/surveillance system that uses image capturing device anddetection devices to reproduce near real-time video stream and audiodata and server linked remotely to a network for transmitting nearreal-time video streams and audio information to server and workstationfor processing and verification.

US Pub. No. 20050110634 with D. Salcedo as inventor for a portablesecurity platform, describes a security system containing a cameradevice configured to generate and monitor video signals in combinationwith processing the alarm data for transmission to a PDA and/or thelike.

US Pub. No. 20050146606 with Y. Karsenty as inventor for a real-timevideo queuing and display system, describes a monitoring system thatprocesses the conditions of remote sites by generating an alert foremergency response unit correspondence.

US Pub. No. 20050237187 with S. Martin as inventor for a real-timesecurity alert & connectivity system for real-time capable wireless cellphones and palm/hand-held wireless apparatus, describes a securitysurveillance system that provides electronic device users real-timeviewing and data access of their home and/or property.

SUMMARY OF THE INVENTION

The present invention relates to surveillance methods. Moreparticularly, the present invention relates to alarm data andsurveillance video display, archiving and distribution.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a chart describing the connection of Remote Viewer(s), DVR(s)and a central server;

FIG. 2 is a flowchart detailing the ongoing communications betweenDVR(s) and central server;

FIG. 3 is a flowchart showing the process flow for alarm monitoringusing an RS232 port connected to a normally-open device output or relay;

FIG. 4 is a flowchart showing the process of server/DVR communicationwhen DVR encounters an alarm condition;

FIG. 5 is a flowchart detailing the communications between remoteviewer(s) and central server during an alarm condition and during anon-alarm condition.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawings in general, the illustrations are for thepurpose of describing a preferred embodiment of the invention and arenot intended to limit the invention thereto.

The present invention advantageously creates a platform where multiplevideo types, created by a multiplicity of different Digital VideoRecorders (DVRs) can be converted into a common format for viewingacross multiple platforms. A problem exists today with many differentDVR's requiring proprietary software or CODECs to be installed on auser's system to view video specific to a manufacturer's DVR. Thispresents a problem when managing a multiplicity of various DVR unitsfrom various manufacturers. To solve this problem, a remote viewerconnects to a central server; the server then downloads the live imagesfrom these various DVR units; and the images are converted to a standardformat and then presented back to the viewer as standard images or as astandardized video stream. Standard video formats currently include.flv, .mp4, .l4v, .avi and .ogv. Video formats will undoubtedly changeand future formats are within the scope of the invention. Alternatively,the standard image and video format are the most common or mostprevalent formats for an area of operation. None of the prior artdescribes a combined system with DVR software processing along with theon-demand features of stored images or real-time images and live videostreaming with image editing and cropping capabilities.

The invention allows end users to access a multiplicity of DVR video andaudio, both live and recorded, by either a) converting video/audio intoa standard format at the DVR itself; or b) converting the video/audio ata central server. Once the video/audio is converted, the video/audio isviewable by standard applications such as and including, but not limitedto, Adobe Flash, Windows Media Player, Apple Computer Quick Time,RealNetworks RealVideo, and the like. The invention further allowscentral management and video alarm monitoring from a central server,integrating access to a multiplicity of DVR's that can be locatedanywhere in the world. With a hosted surveillance solution, asubscription based fee-structure can be implemented without requiring alarge up-front capital investment in server equipment by central alarmmonitoring stations and law enforcement agencies.

The invention further takes advantage of excess computing power thatexists on both PC and standalone DVRs themselves. By converting andprocessing the video on-site, in the DVR itself, rather than convertingand processing the video at the central server, the invention allows theuse of this excess remote computing power to reduce server overhead andspeed up transmission of video clips over the network medium. Thepresent invention further includes the use of mesh computing, whereinDVRs in the vicinity of the DVR that initiated the alarm can assist thealarm-initiating DVR in the processing of video clips and indistributing the processed video clips to responders. The use of a meshnetwork advantageously provides for a resilient alarm system that canprovide for the distribution of the video clips even if the connectionwith the server has failed. Thus, all embodiments described herein usinga server can be substituted with a mesh network of DVRs wherein the meshnetwork performs the functions of the server.

The invention further makes use of newer technology being implemented bylaw enforcement and in law enforcement vehicles across the country. Bycombining the conversion of surveillance video to a standard format anda central server management platform, access to both pre-recorded andlive video becomes available to law enforcement departments, at both thedispatch center and within law enforcement vehicles responding toincidents. This allows for first responders to pull images and videofrom the location as they approach, thereby having an updated, clearvideo overview of the situation they are responding to. Otherwise, as isthe present state of the art, emergency responders have to approach alocation blind—having no idea what is waiting for them once they enter abuilding or location. The invention similarly provides for volunteersand other local personnel to pull images and video at the location toscan for aberrant activity during normal, non-emergency states. Theinvention further allows the use of standard web-browsing applicationsfor both viewing of live and pre-recorded video/audio without requiringthe installation of any software on a remote viewing device. Thisgreatly simplifies access to DVR video/audio.

Thus, the present invention processes and converts captured or liveimages or video with the DVR and neighboring DVRs. This processingincludes using facial recognition/detection capabilities located on theserver/DVRs, using image editing/cropping for image clarification, andusing time-slicing and/or interval counting (alarm event timer).Further, the present invention permits on-demand/on-command features toallow for immediate viewing by requestors, thus permitting emergencyresponse personnel to pull images and video, rather than strictly pushthem to them. The on-demand features also provide for community policingby volunteers or other local personnel to pull images and video to scanfor aberrant activity during normal states. Emergency response personneland community policing volunteers are to be understood as personspreauthorized to access the surveillance video. They are preauthorizedto view the specific cameras that are within their access privilege, andtypically this relates to their jurisdiction or geographic area.

FIG. 1 is a block diagram illustrating the overview of an embodiment ofthe present invention and connected devices. The example embodimentconsists of a server 1 running software 9, a plurality of DVR's'sinstalled at remote locations 2 and 8, a plurality of remote viewers 3and 7 running on computers, connected together via network mediums 4 and5. Network mediums 4 and 5 consist of a connection such as an Internetconnection. For the purposes of this description, DVR 8 and RemoteViewer 7 have been given unique item numbers to illustrate therelationship of specific remote units to specific remote DVRs in theevent of an alarm or when instructions are prepared for a specific DVRconnected to server 1. Server 1 can consist of a single server ormultiple servers connected together. Images and videos are stored in astorage device (not shown) that emergency responders can access via theremote viewers running on computers. Preferably, this is stored on theDVR (as a storage device), on the server(s), and/or separate storagedevice, as appropriate.

FIG. 2 is a flowchart representing normal (non-alarm) communicationbetween server 1 and DVRs 2 and 8. There can be an unlimited number ofDVRs of various makes and models connected via a network medium to theserver. The DVRs communicate with the server on a continuous basis. Datapackets are sent using a network medium 5 via the http protocol, httpsprotocol or other network protocol from the DVRs to the server 1. Thesepackets are sent on a regular interval from the DVRs to the server. Thisallows communication with the DVRs from behind a firewall, as the DVRsare initiating the communication, requiring no special ports be openedon the router or firewall device attached to the DVRs. The packets sentfrom the DVRs to the server contain information such as the healthstatus of the DVR as well as the publicly accessible IP address (step10). If the server has successfully authenticated the DVR'sauthorization to communicate with the server, the server receives thesepackets and processes them accordingly (step 11). If the server has noinstructions for the DVRs, the server returns a packet acknowledging thereceipt of data from the DVR. If the server has instructions for eithera specific DVR or all DVRs globally, those instructions are sent alongwith the packet receipt acknowledgement back to the DVRs. The IPaddresses are preferably the public Internet addresses of the DVRs.Health status messages consist of the status of various hardware andsoftware components on the DVR's. These Health Status Messages canconsist of a variety of items that include, but are not limited to:available hard disk space, CPU temperature, CPU usage, video lost on aDVR's input camera channels, and the like. The server 1 also storesspecific data about the connected DVR 2. This information includes, butis not limited to, the IP address of the DVRs, the username and passwordto connect to the DVRs and the DVR's native interface, the externalports that the DVRs use to communicate over the network medium, and theavailable features of the remote DVRs.

For example, if server 1 has an instruction for DVR 8 to carry out, theinstruction is contained in the packet returned to DVR 8. The DVR 8processes the command (step 12) and returns the result of the command(step 13) to the server 1. These commands include, but are not limitedto, rebooting the DVR 8 unit, instructing the unit to begin capturingvideo clips, instructing the unit to upload the video clips to server,activating onboard relay switches on the remote DVR 8, causing the DVR 8to go into alarm mode, instructing the DVR 8 to make a modification toits preprogrammed workflow or settings and the like. The DVR's areconstantly recording video or video images from predefined, attachedcameras. This video may be stored either locally, such as on the DVR, orremotely, such as on an external device. Each DVR is monitoring forabnormalities within its assigned environment via an input device orfrom analysis of the DVRs' incoming audio or video stream. The inputdevice consists of a hard-wired or wireless input or a data connectionto another device such as an alarm panel or panic button. Video/audiostream analysis consists of either a) motion and/or sound detectedduring an assigned time where no motion or sound should occur; or b) anyother kind of video or audio analysis that detects an abnormality in thevideo or audio input streams. If a DVR detects input from the externaldevice or video analysis indicates an abnormality in the video or audiostream, software running on the DVR generates an alarm condition.

FIG. 3 is a flowchart outlining the process flow for the DVR'smonitoring of a single, closed contact hard-wired connection. Forexample, a DVR with an RS232 port is hard wired using the send andreceive pins of the RS232 port to a normally-open switch or relay. TheDVR outputs some ASCII data (step 14) though the RS232 send pin. At thesame time, the DVR is listening to the receive pin on the same RS232port (step 15). If no data returns, the DVR repeats step 14. If theASCII data is received, it is compared against the sent data in step 14(step 16). If the data doesn't match, the DVR repeats step 14. If theincoming data does match that sent in step 14, the DVR then enters“Alarm Mode” (step 17). Software on the DVR can also monitor other datastreams including but not limited to: RS232 data streams from alarmpanels and other equipment network connected input devices such asEthernet relay/input boards as a means for the software to put DVR intoalarm mode.

FIG. 4 depicts the flowchart of operations between a DVR and serverduring an alarm condition. In this instance we will use DVR 7 as the DVRconnected to the system that enters alarm mode. In this instance also,secondary software capable of executing the methods described as followspreferably resides on the DVR, in addition to the DVR software itself,to carry out these tasks, although the software may alternatively oradditionally reside on the server. Additionally or alternatively,because the software can be housed on all the DVRs, DVRs in the vicinitycan be co-ordinated to execute the software tasks through meshcomputing. This software can be integrated with all Linux and PC-basedDVR's, as well as DVRs with other operating systems. It is alsoimportant to point out that this process can also be accomplished by asecondary computer or computing device located on the same IP network asthe DVR or other DVRs on the same network. This allows the process flowdescribed in FIG. 4 to operate separately from the server, withouthaving access to the filesystem or code on the DVR itself.

When an alarm condition (step 18) occurs on the DVR, the DVR immediatelysends a message (step 19) to the server which the server stores in aninternal database (step 21). The message contains the DVR's uniqueidentifier, alarm condition and alarm data. The server uses thisinformation to generate a unique incident ID containing the alarminformation sent by DVR. This incident ID is hereon used to managefurther communications between DVR (2,8), Server (1) and RemoteViewer(s) (3,7). Next, the DVR captures a snapshot or still image (step22) from attached camera(s) and uploads those image(s) to server forstorage (step 23). The DVR takes video recorded prior to the alarmcondition stored on the DVR or in a remote location, processes the videoimage(s)(step 24) and uploads them (step 25) to the server or local DVRsor computers. Processing of the video image(s) can consist of a) joiningindividual still images together to create a video file; or b)converting a recorded video file on the DVR to a format more suitablefor transmission and display over a network medium.

The purpose of the processing taking place at the DVR, rather than theserver itself, is both to a) save the server from having to process agreat deal of image data—thus saving server CPU overhead; and b)creating a file size and type optimized for both speed of transport overthe network medium and display on either the remote viewer or a varietyof other remote devices. An example of this would be taking video from aDVR, whose video would usually require a specific piece of software fromthe DVR manufacturer to view remotely, converting the video to flv(flash) or another popular video format for display on a remote computeror computing device without requiring the installation of customsoftware from each DVR manufacturer on the remote playback devices.

After the upload of the initial, pre-recorded video from DVR begins, an“Alarm Event Timer” (step 26) starts. The Alarm event timer is aprogrammable increment instructing the DVR to capture clips for adesignated period of time and upload them to the server and/or localDVRs. The DVR starts recording live video and/or audio (step 27) fromthe location, in predefined time increments. A predefined increment maybe 5, 10, 15 seconds or any other increment of time. When thepredetermined video clip length has been reached, the DVR then processeseither recorded live video or a series of still images into a formatsuitable for transport over the network medium (step 28). The DVR thenuploads the clip(s) to the server (step 29) and/or local DVRs whodistribute it through the local mesh network. The DVR then checks to seewhether or not the alarm event timer has expired (step 30). If it hasnot expired, the DVR repeats the process starting from step 27. If thealarm event timer has expired, the DVR returns to normal, non-alarmoperation (step 31). For example, upon an alarm condition, the DVR maybegin recording and uploading clips that are each 10 seconds in length,for a period of 2 minutes after the alarm condition occurred. After thealarm period has expired, the DVR reverts back to normal operation.

One of the methods the invention uses for the capturing of pre-alarmvideo is to “buffer” still images. On the DVR, or on an external deviceor server, a series of still images are captured from assigned camerasat a specific period of time i.e. one image captured every 0.5, 1, 1.5seconds and so on. This periodic capture is defined as the capture rate.These still images are stored for a predetermined period of time. Forinstance, if the desired pre-alarm video clip length is 10 seconds, andthe pre-alarm capture rate 0.5 seconds, the DVR or software would keep atotal of 20 still images before the older image gets over-written. Inthe event of an alarm condition, these images are arranged inchronological older (oldest first) and are stitched together creating avideo file of those captured still images. The advantage of this processis the complete and total control over the video buffering processregardless of the manufacturer of the DVR, and the DVR's own softwareworkflow. For Example—a DVR's native software may not allow for theadjustment of frame rate or image resolution. This can create apotential problem as the speed of the network medium at the DVR locationcan vary greatly. Software residing on the DVR or remotely on a serveror workstation will allow the modification of frame rate and quality tooptimize for transport over network mediums of various speed andcapacity. Once an alarm condition has occurred, the operator at acentral monitoring facility has the ability to “push” the alarm andrelated videos to the emergency response personnel or agency responsiblefor emergencies, for example but not limited to local law enforcementagency, municipal emergency/911 center, fire and rescue, border patrol,government official security, homeland security, military security, andcombinations thereof, responsible for the area where the alarmoriginated. Connection data and contact information for the local lawenforcement agency is stored on the server in a database. Alarms aresent to the law enforcement agency using SMTP (email), an XML connectionor whatever other method is appropriate for the configuration of the lawenforcement agency's dispatch center. This allows the law enforcementagencies to actively view or assess a situation before first respondersarrive on the scene. This is also what allows the law enforcement agentsto view both pre-recorded and live video of an incident to which theyare responding.

Software running on the remote viewer also maintains continuouscommunications with the server via data packets sent over HTTP, HTTPS orsome other protocol. Within those data packets are unique identifiersauthorizing the remote viewer to interact with specific DVR(s), accessdata from the server about specific DVR(s), and authentication toindicate the remote viewer is allowed to interact with the server in thefirst place. Authentication between the remote viewer and the server canconsist of: a) username/password authentication, b) Filtering access tothe server based on the IP address of the remote viewer; or c) any otherappropriate method of providing a secure, authenticated connectionbetween a remote viewer and a server. The remote viewer can consist of astand-alone or integrated application, or may be a web page accessiblethrough an Internet browser. Once authenticated with the server, theremote viewer has either on-demand access or alarm access to specificDVR units assigned to the authenticated remote viewer user. On-demandaccess is defined as the ability of remote viewer to access specificDVRs without an alarm condition being present. Alarm access is definedas a remote viewer being able to access specific DVRs in the event theDVR or another remote viewer has put the DVR in an alarm condition.

FIG. 5 represents a flowchart showing an interaction between a RemoteViewer (RV) and the server. This only represents one way in which the RVinteracts with the server and DVR. This example uses a web browser asthe remote viewer. The user launches the remote viewer (step 32). Oncelaunched, the remote viewer authenticates to the server (step 33) andthe server acknowledges the connection (step 34). The remote viewer thenbegins querying the server for alarms (step 35). The connection to theserver for these constant requests is accomplished in a multiplicity ofways including, but not limited to, AJAX (Asynchronous JavaScript andXML) calls to the server. The server searches its database for anyactive alarms on any DVRs assigned to this authenticated remote viewer(steps 36, 37). If an alarm is present, the RV receives the alarmdetails from the server (step 38). These details include, but are notlimited to: Location of alarm, IP address of DVR, contact information oflocation owner, and the like. The RV then requests a connection from theserver to begin receiving a live video feed (step 39). DVR type andcapabilities are stored in the server database. Depending on the type ofDVR, the server returns code to allow connection either directly to theDVR, or to the server itself (step 40). If the connection is to be madethrough the server, the server then connects to the DVR, captures avideo stream, and converts it to a format viewable by remote viewer. TheRV then queries the server to see if the alarm is still present (step41) and if so, the RV requests any incident media from the server (step43). Incident media includes, but is not limited to: Still Images, VideoFiles, Links, Audio files, and the like. If no incident media ispresent, RV goes into a loop constantly checking if the alarm is presentand checking for new media (returns to step 41). If incident media ispresent, the RV requests thumbnails of the incident media from server(step 44). The RV receives the data from server and displays incidentmedia thumbnails in the RV (step 45). The user can then click on thethumbnails to begin viewing the incident media which is hosted on theserver. The RV then repeats the request from the server for new media(step 42), and enters the media search loop until the alarm condition onthe DVR is no longer present.

There are multiple types of Remote Viewers (RVs). One such RV is aweb-based interface optimized for alarm monitoring facilities for thepurposes of video verification. Another such interface is a web-based orintegrated application designed for view and interaction within lawenforcement patrol vehicles. The patrol vehicle version incorporateslarger buttons and a workflow designed to be used by a touch-screen pc.Another such viewer is one that resides on a mobile computing devicesuch as a smartphone. This allows interaction with incident media andlive video/audio by personnel on foot in the field.

The invention also incorporates image editing and cropping tools. If aperson of interest is found within a piece of incident media, the RVuser has the ability to take a snapshot of a particular frame of thatincident media. This is accomplished by the RV passing back the timecodeor current play time of the video clip back to the server. The server,as it is storing the incident media, uses software to capture a stillimage from within that particular video clip. The server then passes thestill image back to the RV while simultaneously storing the image on theserver. The user of the RV has the option to either add the still imageto the incident media pool, or crop the image for highlighting a regionof interest within the still image. If cropping is desired, the userselects an area of the image containing the region of interest, andthose coordinates are passed back to the server. The server then takesthese coordinates and uses software to crop the image stored above tothat region of interest. The server then saves this cropped image andpasses it on to the RV. The user then has the option to add this croppedimage to the incident media pool or discard the image and return tonormal RV operation.

The invention also incorporates the use of facial detection technology.This allows the automation of defining and capturing faces that arevisible in incident media or live video feeds. Once a face is detected,a snapshot of the face is cropped and added to the incident media pool.This streamlines the process of searching for persons of interest withinvideo feeds and files when an alarm occurs.

All images handled by the server are archived either for a set period oftime or in perpetuity. A regular logging and backup process ensuresimages and data related to an alarm condition are made available in thefuture. This creates an “Audit Trail” allowing for specific informationincluding, but not limited to: time the alarm was generated, user thatresponded to the alarm, video images seen by the operator, video imagesviewed by law enforcement, and the like. This audit trail and archivedvideo will be useful for prosecution of suspects should the archivedfootage be needed. This preserves the chain of custody required toutilize video evidence in a court of law.

DVR owners also have the ability to make specific cameras attached totheir DVRs available for viewing by law enforcement on-demand, withoutan alarm condition present on the DVR itself. This allows lawenforcement to view these select cameras in the course of investigatinganother event in the vicinity of the DVR location. The vicinity of theDVR is represented on a graphical map on a computer display allowing lawenforcement agencies quick access to available cameras in the area of anincident. Graphical map consists of either a Google, Bing, or other mapthat allows the placement of specific geolocation points on the mapitself. The cameras available to law enforcement including all relevantconnection data, such as by way of example and not limitation, IPaddresses, usernames, and passwords, to the cameras will be stored on aserver in a database.

For example, as shown in FIG. 1, DVR 8 goes into alarm mode. Video fromDVR 8 is viewed on a law enforcement dispatch center's Remote Viewer.Video viewed from DVR shows suspect vehicle make and color. The dispatchcenter and/or emergency responders are presented with a graphical mapshowing available secondary DVRs 2 in the vicinity that have been madeavailable to law enforcement. Live video from cameras from thesesecondary DVRs 2 are either automatically displayed on the operator'sscreen or the operator clicks a graphical icon to initiate the live feedon his/her screen. The secondary DVRs 2 might be connected to anexternal camera with a view of the street. The dispatch and/or emergencyresponders could use the view from secondary DVRs 2 to assist intracking the location of suspect vehicle captured by DVR 8.

In the event of an alarm event where a DVR captures an image of asuspect vehicle, other DVRs in the vicinity are placed in an alert modeeither automatically or at the operator/user's instruction to be on thelookout for an object fitting the description of the suspect vehicle.The image of the suspect vehicle is stored on the server 1 or sent tothe DVR units made available for use by law enforcement. Software on theDVR or on the Server analyzes live video images for objects matching theimage of the suspect vehicle. The matching is accomplished using anobject tracking application. Upon the identification of an objectmeeting the description of the suspect vehicle by the software on DVR orserver, the image is automatically presented to operator on his/herscreen along with the location information of the DVR that captured thesuspect vehicle. Additionally, other existing cameras, such as municipalcameras, may be included in this object tracking search as well bysending images to the server for processing.

Furthermore, the DVRs in the vicinity and in the network may proactivelybroadcast video clips of the suspect(s) to law enforcement personnel andthe like, thus alerting them to the fact that an alarm condition hasoccurred and simultaneously providing them with identifying information.The video clips can be received and retransmitted by DVRs in thevicinity but not on the network, thus creating a larger alarm networkwithout requiring normal network communication.

In the event of a capture of the facial details of a person of interest,an operator of the server initiates a facial recognition search lookingfor the person of interest on DVRs and cameras in the vicinity of thealarm. The facial recognition software is located on the server or theDVR units themselves. Software on the DVR or server analyzes videoimages for objects that match that of a human face. A still image of theperson of interest is uploaded to the server, where software extractsthe specific data from the facial image to initiate recognition. DVRs inthe vicinity of the alarm location either begin transmitting stillimages from cameras that are capable of capturing images of individuals,or the server begins remotely pulling images from the DVRs to beginsearching for a facial recognition match. Facial data points areextracted from these uploaded/downloaded images and compared against thedata points from the original image capture of the suspect. If a matchis found within a margin of error, the newly captured image appears onthe operator's/User's screen along with the DVR location data where thesuspect was identified.

For example, Suspect commits a crime in a retail location A. Clerk atretail location A triggers alarm and DVR enters alarm mode. A camera orcameras in retail location A capture an image of the suspect in whichfacial data points can be extracted. This image is uploaded to theserver. Additionally or alternatively, the image is distributed to otherDVRs in the network. Law enforcement is made aware of the alarm andlive/recorded video is displayed on the operator/user's screen. An imageis captured of the suspect's face and is presented to the operator/useron their remote viewer. Operator/user is also made aware of theavailability of a facial recognition search of DVRs in the vicinity ofthe alarm and either commences a facial recognition search, or thefacial recognition search is initiated automatically by server or remoteviewer. Server begins receiving or requesting images from DVRs in thevicinity and processing for facial data. A block away, an image iscaptured of an individual in another retail establishment—retailestablishment B. This image is processed by the facial recognitionsoftware on server, and it is found to be a 90% match to suspect wantedin connection with incident at retail establishment A. The capturedimage from retail establishment B is displayed on the remote viewer ofoperator/user along with the location details of retail establishment B.Operator/user is then able to dispatch the appropriate response toretail establishment B to apprehend suspect.

Certain modifications and improvements will occur to those skilled inthe art upon a reading of the foregoing description. The above-mentionedexamples are provided to serve the purpose of clarifying the aspects ofthe invention and it will be apparent to one skilled in the art thatthey do not serve to limit the scope of the invention. All modificationsand improvements have been deleted herein for the sake of concisenessand readability but are properly within the scope of the presentinvention.

What is claimed is:
 1. A method for providing surveillance video toresponders, the method steps comprising: a. providing a surveillancesystem, the system including at least one remote viewer running on acomputer and a multiplicity of different format DVRs creating multiplevideo types for providing surveillance to a surveillance area, a storagedevice for storing video, and at least one central server; the remoteviewer, DVRs, storage device and server connected via a network; b.streaming live surveillance video from a surveillance area to thenetwork; c. converting the live streaming surveillance video to a formatsuitable for display on a multiplicity of different remote viewers andfor transport over a network media; d. streaming the live convertedsurveillance video to the responders through the at least one remoteviewer.
 2. The method of claim 1, wherein the surveillance video isautomatically converted to the video format by the DVR.
 3. The method ofclaim 1, wherein the surveillance video is automatically converted tothe video format by the remote server.
 4. The method of claim 1, whereinthe format suitable for transport over a network media is an Internetbrowser video format selected from the group consisting of .flv, .mp4,.l4v, .avi, .ogv, mjpeg, VP8, WebM, and combinations thereof.
 5. Themethod of claim 1, further including the step of capturing pre-alarmvideo by buffering still images.
 6. The method of claim 1, wherein theprocessing of video images includes image cropping.
 7. The method ofclaim 1, further including graphical mapping of the broadcasting DVRs inthe vicinity of the alarm DVR.
 8. The method of claim 1, furtherincluding on-demand requesting for immediate viewing of convertedsurveillance video by responders.
 9. The method of claim 1, furtherproviding access by volunteers or other local personnel to pull imagesand video for community policing.
 10. The method of claim 1, wherein theDVR is part of a mesh network and the video processing is performed bythe mesh network.
 11. The method of claim 1, wherein the DVR is part ofa mesh network and the converted surveillance video is distributed tothe mesh network and made available to responders.
 12. A system ofproviding video surveillance, the system comprising: a. a multiplicityof different format DVRs creating multiple video types for providingsurveillance to a surveillance area; b. at least one remote viewerrunning on a computer; c. the at least one remote viewer and DVRsconnected via a network; d. the DVRs operable to capture live video; e.the DVRs operable to convert the live video to a format suitable fordisplay on a multiplicity of different remote viewers and for transportover the network media; f. the DVRs operable to stream the livesurveillance video during conversion to the at least one remote viewer.13. The system of claim 12, wherein each DVR is operable forbroadcasting a graphical mapping of other broadcasting DVRs in thevicinity of the DVR.
 14. The system of claim 12, wherein the at leastone remote viewer includes remote viewers by volunteers or other localpersonnel operable to pull images and video for community policing. 15.A system of providing video surveillance, the system comprising: a. amultiplicity of different format DVRs operable to create multiple videotypes for providing surveillance video of an surveillance area; b. aserver operable to convert the surveillance video to a format suitablefor display on a multiplicity of different remote viewers and fortransport over the network media; c. at least one remote viewer runningon a computer; d. the remote viewer, server and DVRs connected via anetwork; e. the DVRs operable to stream the captured video to theserver; f. the server operable to immediately convert and immediatelystream the surveillance video to the at least one remote viewer.
 16. Thesystem of claim 15, wherein each DVR is operable for broadcasting agraphical mapping of other broadcasting DVRs in the vicinity of the DVR.17. The system of claim 15, wherein the at least one remote viewerincludes remote viewers by volunteers or other local personnel operableto pull images and video for community policing.